Broadcast data access system for multimedia clients in a broadcast network architecture

ABSTRACT

A broadcast data access system is provided for receiving broadcast data by applications residing on a multimedia client, where the broadcast data is a set of modules on a data carousel that are being broadcast over a broadcast network. The broadcast data access system includes an interest manager configured to store a plurality of interests, such that each interest identifies an available module on the data carousel being requested by an application. The system further includes at least one application having registered an interest for a first module with the interest manager, and a dispatcher distributing the first module to the requesting application by accessing the interest manager.

BACKGROUND OF THE INVENTION

[0001] The present invention relates generally to a broadcast dataaccess system, and more particularly to an architecture for supportingapplications that receive broadcast data from a data carousel over abroadcast network.

[0002] In a broadcast network architecture, various types of data can bedelivered from a server to a group of multimedia clients. Typically,multimedia clients do not have enough resources to store all of the datathat is being broadcast over the network. Even if the client could storeall of the data, there is no guarantee that the client will receive anerror-free copy of the data in a single transmission of the data.Moreover, the client has no way of requesting that a server resendmissing or defective data. Since the data is being sent to many clients,it might also be prohibitive to resend missing or defective data to eachof the clients which request it.

[0003] A broadcast data carousel is commonly used for transporting datain a broadcast environment. This underlying mechanism for transportingdata is defined in the MPEG-2 DSM-CC specification (i.e., ISC/IEC13818-6). Using this mechanism, the server repeatedly sends data over aperiod of time so that a client which is interested in the data mayreceive it only when it is required. If a client misses some of the dataor receives defective data, it waits for the next broadcast of the datato receive any data that it may need.

[0004] A Broadcast File System (BFS) provides a layer on top of thebroadcast data carousel that hides the details of the underlyingtransport mechanism from the server and clients. In particular, BFScreates a mapping between the carousel/file number and a module name. Asa result, the server and clients view the broadcast data as a standardhierarchical file system similar to files found on a disk operatingsystem.

[0005] Therefore, it would be desirable to provide a broadcast dataaccess system for receiving broadcast data from a data carousel in asimple, efficient, and flexible manner. It should support multiple datasources between the broadcast network and the multimedia client, suchthat each source can receive a different form of encoded broadcast data.In addition, the broadcast data access system should be able toefficiently process data packets received in a non-sequential order, aswell as simultaneously fulfill multiple requests for the same datapackets by different applications. To lessen processing overhead,filters are dynamically installed on the client. Lastly, the presentinvention should provide a method for downloading and synchronizing adirectory module with the content of the data carousel being broadcastto the client.

SUMMARY OF THE INVENTION

[0006] In accordance with the teachings of the present invention, abroadcast data access system is provided for receiving broadcast data byapplications residing on a multimedia client, where the broadcast datais a set of modules on a data carousel that are being broadcast over abroadcast network. The broadcast data access system includes an interestmanager configured to store a plurality of interests, such that eachinterest identifies an available module on the data carousel beingrequested by an application. The system further includes at least oneapplication having registered an interest for a first module with theinterest manager, and a dispatcher distributing the first module to therequesting application by accessing the interest manager.

BRIEF DESCRIPTION OF THE DRAWINGS

[0007]FIG. 1 is a diagram depicting the basic components in a typicalbroadcast file system in accordance with the present invention;

[0008]FIG. 2 is a data flow diagram illustrating a preferred embodimentof the broadcast data access system of the present invention;

[0009]FIG. 3 is a block diagram showing the software architecture forthe broadcast data access system of the present invention which resideson each multimedia client;

[0010]FIG. 4 is a diagram showing dynamic filter installation inaccordance with the present invention;

[0011]FIGS. 5A and 5B are a detailed flowchart illustrating a preferredembodiment of the data block processor of the present invention; and

[0012]FIG. 6 is a detailed flowchart illustrating a preferred embodimentof a portion of the data block processor that handles downloading andsynchronizing the BFS directory onto the client.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

[0013] The following description of the present invention is merelyexemplary in nature and is in no way intended to limit the invention orits uses. Moreover, the following description, while depicting abroadcast data access system that is designed to reside on aconventional set top box, is intended to adequately teach one skilled inthe art to make and use a similar architecture for a variety of consumermultimedia clients including, but not limited to, intelligenttelevisions, Internet terminals and advanced DVD players.

[0014] A Broadcast File System 10 (BFS), as depicted in FIG. 1, providesan architecture for delivering various types of data from a BFS server12 (or group of servers) to a plurality of multimedia clients 14 over abroadcast network 16. It is also envisioned that a two-way communicationnetwork could be used in conjunction with the broadcast file system 10of the present invention. The underlying mechanism for transporting dataacross the network 16 relies on a broadcast data carousel which isdefined in the MPEG-2 DSM-CC specification (i.e., ISC/IEC 13818-6).Typically, broadcast data is grouped into files that are subdivided intofixed-size data blocks and then broadcast in a non-sequential orderusing the data carousel mechanism. However, BFS 10 of the presentinvention provides a layer on top of the broadcast data carousel thathides the details of this underlying transport mechanism from the server12 and clients 14. Within a data carousel, individual data files arecalled modules. Since modules are identified by numbers (not names), BFS10 creates a mapping between file numbers and module names. In this way,the server 12 and clients 14 of BFS 10 view these modules in a standardhierarchical file system similar to files found on a disk operatingsystem.

[0015] BFS server 12 is the component responsible for storing,assembling and delivering modules across the network 16. While thefollowing discussion is provided with reference to one data carousel, itis readily understood that the explanation is applicable to more thanone data carousel. A top level data carousel contains at least onemodule known as the BFS directory which includes the module names forall of the other modules on this or any other data carousel. As modulesare added to the data carousel, BFS server 12 creates a module name(i.e., identifier) for each new module and then updates the BFSdirectory structure. Similarly, when modules are updated and/or deletedfrom the data carousel, the BFS directory structure is updated by BFSserver 12. Applications residing on a multimedia client 14 in turnutilize the BFS directory to access modules contained on the broadcastdata carousel. The network 16 may employ any underlying transportprotocol (e.g., MPEG transport and/or UDP/IP) which has the ability todeliver data packets across the network to the client.

[0016] A broadcast data access system 30 of the present invention servesas the interface between the set of modules contained on the datacarousel 32 and the various applications residing 34 on multimediaclient 14. Referring to FIG. 2, the broadcast data access system 30 oneach multimedia client 14 includes an interest manager 36 that isconfigured to store a plurality of interests. To receive broadcast datafrom the data carousel 32, an application 34 registers an interest withthe interest manager 36 (e.g., a first application registers a firstinterest requesting a first module from the data carousel). For purposeof this discussion, the term Aapplication@ signifies any softwaremodule, including the operating system, that may reside on themultimedia client 14. For each module received by the multimedia client14, a dispatcher 38 accesses the interest manager 36 to determine if anyapplication residing on that client 14 has requested that module, and ifso distributes that module to the appropriate application 34.

[0017] A more detailed implementation of the broadcast data accesssystem 30 is shown in FIG. 3. Preferably, data access system 30 supportsat least two data sources: a QAM modulated in-band source and a QPSKmodulated out-of-band source. In the case of a set-top box, thesemultiple data sources may be received via an HFC connection. Since thedata access system 30 is designed to support different types of datasources, it provides a data source processor 42 for each of these datasources. As data blocks arrive at the client, data source processor 42performs source specific processing on each data block, including butnot limited to, removing header information, verifying checksum anddecompression.

[0018] Once pre-processed by a data source processor 42, data blocks arepassed along (in DSM-CC format) to a dispatcher 38. Dispatcher 38 mayperform some additional data block verification (e.g., check payloadlength). However, based on the particular type of DSM-CC message, thedispatcher 38 is primarily responsible for directing each incoming datablock to an appropriate processor. Data access system 30 currentlyincorporates three specific processors: a download informationindication (DII) processor 44 which receives DSM-CC download informationindication (DII) messages, cancel processor 46 which receives DSM-CCmessages that indicate when a module has been removed from the datacarousel, and data block processor 48 which receives all other types ofdata blocks. For the in-band QAM channel, data access system 30 alsointeracts with a TV manager 52 which provides the functionality toselect and manipulate in-band data source.

[0019] When an application requests to “open” (or retrieve) a module onthe data carousel, it registers this request with the interest manager36. The interest manager 36 maintains a list of modules which the dataaccess system 30 is currently interested in receiving from the datacarousel. Thus, an interest exists for every application request. Anidentifier (e.g., source id, carousel id, module id, version id, ect.)that uniquely identifies the requested module as well as an identifierfor the requesting application are stored in a data structure 37associated with the interest manager 36. Once an interest has beenregistered by the an application 34, all data blocks that match thatinterest are processed by the data block processor 48.

[0020] In addition to registering each application request, an open filecomponent 36A of the interest manager 36 will interface with the BFSdirectory 50 to ensure that the requested module exists on the datacarousel. Generally, DII messages contain a directory of all of themodules on the carousel and are periodically received (e.g., multipletimes per second) by the DII processor 44. As part of thissynchonization process, the open file component 36A also verifies thatthe module exists in accordance to the most recently received DIImessage. Next, it checks that the version number for the moduleretrieved from the BFS directory matches the version for that moduleincluded in the DII message. In this way, the interst manager 36 ensuresthat the applications request to open a module is synchronized with themodule contained on the data carousel. Because modules are delivered onmultiple sources at different rates, it is important to implement thissynchonization process; otherwise an application may read data fromeither an older version of the module or possibly even a newer versionof the module. It is also envisioned that a filter may be dynamicallyinstalled by the open file component 36A that allows DII messages forthis carsousel to pass through to the dispatcher 38. Once thesynchronization process is complete, the filter is removed so that DIImessages will not unnecessarily pass through to the dispatcher 38.

[0021] To more efficiently process incoming data blocks, interestmanager 36 also dynamically installs filters for each requestedinterest. Referring to FIG. 4, when an application 34 registers aninterest, the interest manager 36 installs a filter in the correspondingdata source processor 42. A module identifier encapsulated in each datablock is compared to each registered interest. Data blocks notassociated with any registered interest are discarded before anyunnecessary processing occurs on the client. In this way, only datablocks associated with a registered interest undergo pre-processing inthe data source processor 42 and are allowed to pass through to thedispatcher 30. Once all of the data blocks for a particular interesthave been received by the client, interest manager 36 removes the filterfor that interest.

[0022] Typically, a data carousel broadcasts all of the data on thecarousel before it re-broadcasts any of the data. Therefore, when anapplication makes a new data request, the response time depends on thedata's location relative to where the carousel is in the broadcastcycle. For example, a carousel having ten data blocks may be currentlybroadcasting the fifth data block. An application that requests datacontained in the seventh block will receive that data faster than anapplication that requests data contained in the ninth block. If it isthe eighth block that is currently being broadcast, the reverse is true:an application that requests data contained in the ninth block willreceive that data faster than an application that requests datacontained in the seventh block.

[0023] Therefore, data block processor 48 reads the data from a datacarousel as it is broadcast; it does not wait for the beginning of thedata to begin reading. For instance, an application may be interested ina module contained in blocks 2 to 6. If it starts reading as block 4 isbroadcast, data block processor 48 copies the data in block 4 to theapplication's buffer and then reads the data in each successive blockthat is broadcast. Subsequent data blocks associated with the requestedmodule (i.e., blocks 5, 6, 2, and 3) are copied to the application'sbuffer, whereas data that is not part of the module (i.e., blocks 7, 8,9, 10 and 1) are discarded.

[0024]FIGS. 5A and 5B are a flowchart showing a more detailedimplementation of the data block processor 48. Start block 100 beginsthe processing for each incoming data block. In block 102, data blockprocessor 48 interfaces with the interest manager 36 to retrieve aregistered interest. Decision block 104 determines if the incoming datablock matches this interest, and if so continues processing in block106. If the incoming data block does not match the registered interest,data block processor 48 retrieves the next interest. Because all of theinterests are evaluated for each data block, multiple interests can beserved by the same incoming data block.

[0025] Decision block 106 compares the version number for each incomingdata block to the expected version number contained in the BFSdirectory. This is important because a module can be changed on thecarousel as individual data blocks for that module are being read bydata access system 30. If the version numbers match, then processingproceeds to decision block 110. On the other hand, if the version numberdoes not match, processing branches to an error subroutine 108.

[0026] Next, decision block 110 determines if a data block falls withinthe desired range of data blocks. For each data blocks within thedesired range, Block 112 sets a Read Block indicator. Data blocksoutside the desired range are discarded in block 114. Read Blockindicator is an array data structure used to monitor which data blockshave been read from the data carousel. Each bit in the array representsa data block in the requested module, such that if the bit is on (i.e.,set to 1), then the block has been read, but if the bit is off (i.e.,set to 0), then the block has not been read. Using this indicator allowsdata block processor 48 to receive data blocks in any order from thedata carousel, and thus eliminates any unnecessary memory copies.

[0027] By evaluating the Read Block Indicator, decision block 116determines if an incoming data block has been previously received by theclient. For previously unread data blocks, block 120 sets theappropriate bit in Read Block indicator and then copies the data blockto the corresponding application buffer space (or alternatively placedin cache memory) in block 122. On the other hand, previously read datablocks are discarded in block 118. Decision block 124 evaluates whetherall of the data blocks for a requested module have been read (i.e., allbits set to 1). Once all of the data block have been read, data blockprocessor 48 interfaces with interest manager 36 to remove the interestand filter for that requested module in block 126, but in either caseprocessing continues by reading the next interest in block 102. Once allof the interests have been evaluated with respect to an incoming datablock, processing is completed for that data block.

[0028] Since the data access system 30 receives data from multiple datasources, each of which may have different content as well as differentdata rates, the BFS directory may not always be in synch with thecontent of the data carousel being broadcast to the client. For example,a module (including the BFS directory module) can be changed on thecarousel as individual data blocks for that module are being read bydata access system 30. Therefore, the data block processor 48 alsoprovides a method for downloading and synchronizing the BFS directory onthe client.

[0029]FIG. 6 is a flowchart showing a portion of the data blockprocessor 48 that handles the downloading of the BFS directory.Initially, when a set-top box on an (RF) broadcast network boots, aDSM-CC user-to-network configuration message is received at the clientwhich contains the source ID, carousel ID and module ID for the BFSdirectory. Based on this information, Block 140 installs a filter thatallows (any version of) BFS directory data blocks to pass through thedispatcher 38. As a result, the current version of the BFS directory isretrieved from the data carousel. In a preferred embodiment, BFSdirectory structure is only delivered over the out-of-band source (whichby definition is guaranteed to be available to data access system 30),and thus this filter only need be applied to that data source.

[0030] Decision block 144 determines when a BFS directory data blockarrives, and if so block 146 reads and parses each incoming data blockto construct the BFS directory structure. In the event an error occursduring the downloading process, decision block 148 returns processing toblock 142 for re-installation of the initial BFS directory filter. Thisensures that the current BFS directory is always downloaded from thedata carousel.

[0031] Without an error, block 150 checks any registered interestsagainst the newly downloaded BFS directory. At boot up, there will be noregistered interests. However, for subsequently downloaded BFSdirectories, DII processor 44 interfaces with the interest manager 36 toverify registered interests. If a registered interest no longer existsor has been updated on the data carousel (as indicated by the newlydownloaded BFS directory), then the interest is marked for deletion.Block 152 then installs (e.g., cached in memory) the newly downloadedBFS directory onto the client for use by data access system 30.

[0032] Once a BFS directory has been successfully downloaded, block 154installs a different filter which only passes data blocks whose versionnumber does not match the version number of the downloaded BFSdirectory. When the BFS directory is changed on the server, the versionnumber will be modified, thereby allowing BFS directory data blocks toagain pass through the dispatcher 38. Beginning in block 144, a new BFSdirectory can then be downloaded. In this way, data block processor 48does not process redundant BFS directory information.

[0033] The foregoing discloses and describes merely exemplaryembodiments of the present invention. One skilled in the art willreadily recognize from such discussion, and from the accompanyingdrawings and claims, that various changes, modifications and variationscan be made therein without departing from the spirit and scope of thepresent invention.

What is claimed is:
 1. A broadcast data access system for receivingbroadcast data by applications residing on a multimedia client, thebroadcast data being a set of modules on a data carousel that arebroadcast over a network, comprising: an interest manager beingconfigured to store a plurality of interests, such that each interestidentifies an available module on the data carousel and a requestingapplication; a first application on the multimedia client beingoperative to register a first interest with said interest manager, saidfirst interest representing a first module on the data carousel; and adispatcher receiving a plurality of modules from the data carousel,including said first module, and being operative to distribute saidfirst module to said first application by accessing said interestmanager.
 2. The broadcast data access system of claim 1 wherein saiddispatcher using a module identifier encapsulated in said first moduleto access said interest manager, thereby determining said firstapplication.
 3. A broadcast data access system of claim 1 wherein saidinterest manager being operative to remove said first interest afterdistributing said first module to said first application.
 4. Thebroadcast data access system of claim 1 further comprises a secondapplication being operative to register a second interest with saidinterest manager, said second interest representing said first module onthe data carousel, and said dispatcher being operative to distributesaid first module to said first application and said second application.5. The broadcast data access system of claim 1 wherein said first modulebeing broadcast as a plurality of data packets in a non-sequential orderover the data carousel, and said dispatcher being operative todistribute each of said data packets to said first application and toremove said first interest before receiving a duplicate data packetassociated with said first module.
 6. The broadcast data access systemof claim 1 further comprising a first data source connection between thenetwork and the multimedia client and a second data source connectionbetween the network and the multimedia client, such that said dispatcherreceiving said plurality of modules from at least one of said first andsecond data source connections.
 7. The broadcast data access system ofclaim 6 further comprising a data source processor connected betweeneach of said data source connections and said dispatcher for performingdata source specific processing on each incoming module.
 8. Thebroadcast data access system of claim 1 further comprising a broadcastfile server accessible through the network, said broadcast file serverbeing configured to store said plurality of modules and operative tobroadcast said plurality of modules to the multimedia client.
 9. Abroadcast data access system for receiving broadcast data byapplications residing on a multimedia client, the broadcast data being aset of modules on a data carousel that are broadcast over a network,comprising: a first application on the multimedia client being operativeto register a first interest with an interest manager, said firstinterest representing a first module on the data carousel; said interestmanager being configured to store a plurality of interests, such thateach interest identifies an available module on the data carousel andthe requesting application; a data source processor receiving at least afirst module and a second module from the data carousel and beingconfigured by said interest manager, in response to said first interest,to filter said second module; and a dispatcher receiving said firstmodule from said data source processor and distributing said firstmodule to said first application by accessing said interest manager. 10.The broadcast data access system of claim 9 wherein said dispatcherusing a module identifier encapsulated in said first module to accesssaid interest manager, thereby determining said first application. 11.The broadcast data access system of claim 9 wherein said interestmanager being operative to remove said first interest after distributingsaid first module to said first application.
 12. The broadcast dataaccess system of claim 9 further comprises a second application beingoperative to register a second interest with said interest manager, saidsecond interest representing said first module on the data carousel, andsaid dispatcher being operative to distribute said first module to saidfirst application and said second application.
 13. The broadcast dataaccess system of claim 9 wherein said first module being broadcast as aplurality of data packets in a non-sequential order over the datacarousel, and said dispatcher being operative to distribute each of saiddata packets to said first application and to remove said first interestbefore receiving a duplicate data packet associated with said firstmodule.
 14. The broadcast data access system of claim 9 furthercomprising a broadcast file server accessible through the network, saidbroadcast file server being configured to store said plurality ofmodules and operative to broadcast said plurality of modules to themultimedia client.
 15. A method for accessing broadcast data byapplications residing on a multimedia client, the broadcast data being aset of modules on a data carousel that are broadcast over a network,comprising the steps of: configuring an interest manager to store aplurality of interests, such that each interest identifies an availablemodule on the data carousel and the requesting application; registeringa first interest by a first application with said interest manager, saidfirst interest representing a first module on the data carousel;installing a filter to pass said first module, in response to said firstinterest, by said interest manager; receiving at least a first moduleand a second module at a data source processor on the multimedia client;filtering said second module by said data source processor; anddistributing said first module to said first application by accessingsaid interest manager.
 16. The method of claim 15 wherein the step ofdistributing said first module further comprises determining said firstmodule based on a module identifier encapsulated in said first moduleand identifying said first application by using said module identifierto access said interest manager.
 17. The method of claim 15 furthercomprises the step of removing said filter after distributing said firstmodule to said first application.
 18. The method of claim 15 furthercomprises the steps of: registering a second interest by a secondapplication with said interest manager, said second interestrepresenting said first module on the data carousel; distributing saidfirst module to said second application by accessing said s interestmanager; and removing said second interest after distributing said firstmodule to said second application.
 19. The method of claim 15 whereinthe step of distributing said first module further comprisesbroadcasting said first module as a plurality of data packets in anon-sequential order over the data carousel and distributing each ofsaid data packets to said first application before receiving a duplicatedata packet associated with said first module.